package com.dy.design_pattern_study.design_pattern_principles;

/**
 * @CreateBy zhangdingyi
 * @Date 2023-03-13
 * @Content 单一性原则 -简单的讲就是，一个类仅负责自己的一块地皮（细致分工）
 * 就一个类而言，应该仅有一个引起它变化的原因
 * 单一职责原则（SRP）：就一个类而言，应该仅有一个引起它变化的原因
 * <p>
 * 比如 方块游戏的设计
 * 下落、旋转、碰撞判断、移动、堆积这些游戏逻辑，如果仅用一个类来实现，那么其耦合程度极高，
 * 就会削弱或者抑制这个类完成其他职责的能力。
 * <p>
 * 如果一个类承担的职责过多，就等于把这些职责耦合在一起，一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力。
 * 这种耦合会导致脆弱的设计，当变化发生时，设计会遭受到意想不到的破坏
 * <p>
 * 那么如何针对一个类来设置对应的属性呢？
 * 其实要去判断是否应该分离出类来，
 * 就是如果你能够想到多于一个的动机去改变一个类，那么这个类就具有多于一个的职责，就应该考虑类的职责分离。
 * 简单的说，就是
 * 游戏设计的功能，在下落的时候可以进行旋转，因此这个游戏逻辑下落就应该设置单一职责，
 * 不能把旋转的功能一起加入进去，应该考虑把这个类分成两种一起来实现这个下落与旋转的功能。
 * （当然了，这个具体的分析也得有经验的积累，想要 一蹴而就 是非常可怕的）
 * <p>
 * 我们却是要在类的职责分离上多思考，做到单一职责，这样你的代码才是真正的易维护、易扩展、易复用、灵活多样。
 * <p>
 * 本章节主要讨论的是类的单一职责问题，类的功能越单一，那么就可以对其进行较多的复用
 */
public class SinglePrincipleStudy {

}
